MacFormat 1996 January/macformat-033.iso/mac/Shareware City/Developers/VideoToolbox/Video synch

Text File | 1995-11-08 | 56.7 KB | 893 lines | [TEXT/R*ch]

VideoToolbox: Video synch
November 8, 1995

WHAT'S NEW:
•Surprise: 7500/100 video is MUCH faster than 9500/120--see table below.
•Update on our request to Apple for support of high frame rates--see HIGH FRAME
RATES.
•"Video bugs" has been appended to the end of this document.

The VideoToolbox allows you to produce accurately controlled visual stimuli. This
document deals with time; how to make sure each video frame shows what you want.
After reading this document, you'll probably want to look at the accompanying
"Video bugs" document, and run the "TimeVideo" program on your Mac, to give all
your video cards a thorough workout and learn their timing characteristics. If
you have many computers, put TimeVideo on a floppy and run it from the floppy on
each machine; all the results will accumulate in a single report file. I am
always glad to receive copies of the TimeVideo report on new machines.

MOVIES. It's easy to show movies on a Mac. Create all your GWorlds in memory
ahead of time, and then call CopyWindows() to copy one image after another to the
screen (e.g. try the demos NoiseVBL or SandStorm). For any serious application
you'll want a real-time movie, one image per video frame, so you'll want to wait
for a new frame before copying each image, using one of the synchronization
techniques described below (e.g. try the demo NoiseVBL). (Incidentally, some
people have mistakenly assumed that page switching is the ONLY way to achieve a
real-time movie. It's not. Video cards serially read the image pixels one by one
during most of the frame period, e.g. 15 ms. If your computer starts writing at
the beginning of the new frame and writes the pixels faster than they're read
you'll display a whole new image on each frame.) How big a movie you can show in
real time will depend on how fast your processor is. TimeVideo does this timing
for you, telling you what fraction of the screen you can fill with a real-time
movie. If you can't do a full-screen movie and you need to show multiple patches,
consider showing several small movies, updating only the dynamic parts of the
screen. (We assume that you are not limited by memory, and therefore do not
discuss Apple's QuickTime, whose principal purpose, beyond making movies
portable, is to minimize storage requirements by using image compression.) Most
Macs access built-in video much more quickly than NuBus video. Here are data
rates for showing movies on a few machines:

Power Mac 7500/100: Built-in 36 MB/s
Power Mac 7200/90 with 2 MB VRAM: Built-in 33 MB/s
Power Mac 7200/90 (with standard 1 MB VRAM): Built-in 25 MB/s
Power Mac 7200/75 (with standard 1 MB VRAM): Built-in 25 MB/s
Power Mac 8500/120: Built-in 25 MB/s, ATI PCI card 17 MB/s
Power Mac 9500/120: ATI PCI card 17 MB/s, Radius Thunder 30/1600 PCI card 4 MB/s
Power Mac 8100/80: Built-in VRAM 18 MB/s, DRAM 17 MB/s, "Built-in AV" 15 MB/s
Power Mac 7100/66 (w AV,secondary cache): Built-In VRAM 17 MB/s, DRAM 13 MB/s.
Workgroup Server 6150/66: Built-In DRAM 16 MB/s.
Power Mac 6100/60AV (w secondary cache): Built-in VRAM 12 MB/s, DRAM 15 MB/s
Quadra 840av: Built-in 12 MB/s, NuBus 9 MB/s
Quadra 630: Built-in 12 MB/s
Quadra 950: Built-in 11 MB/s, NuBus 5 MB/s
LC 475: Built-in 10.6 MB/s
Centris 660AV: Built-in 10.2 MB/s
Quadra 660AV: Built-in 9.6 MB/s
Quadra 900: Built-in 9.5 MB/s, NuBus 5.5 MB/s
Centris 610: Built-in 9 MB/s
Centris 650: Built-in  5.8  MB/s
LC III: Built-in  5.8  MB/s
IIci: Built-in 5.5 MB/s, NuBus 3.7 MB/s
II with Rocket 68040 accelerator: NuBus 4.0 MB/s
PowerBook 520/540: 3.6 MB/s
IIfx: NuBus 3.0 MB/s (8•24GC "acceleration" reduces it 1.5 MB/s)
PowerBook 160: Built-in LCD screen and video port 3.0 MB/s
IIcx: NuBus 2.7 MB/s
II: NuBus 2.7 MB/s
LC II: Built-in  2  MB/s
PowerBook 170: Built-in LCD screen 1.6 MB/s, SCSI Radius PowerView 1 MB/s
Classic: Built-in 1.7 MB/s
Classic II:  Built-in 1.4 MB/s
SE: Built-in 0.9 MB/s
Plus: Built-in 0.6 MB/s
The quoted rate is the best, across all pixel depths and across CopyBits and
CopyBitsQuickly, which are usually within +/-20% of each other. CopyBits, being
part of QuickDraw, always runs native.

I haven't got my own PCI Mac yet (got four 7500's on order), but Mal Semple and
Dan Sanes lent me their 8500 and 7500 for a few days and several people have
sent me TimeVideo reports on the PCI Macs. The first four lines in the table
above were a big surprise to me. CopyBits is slowest on the 9500, faster on the
7200 and 8500, and yet faster on the 7500. This is confirmed by an engineer at
Apple, "Yes, this actually does make sense: The 7500 and 8500's internal video is
on a private PCI bus that runs synchronous with the processor bus. Thus, on the
7500 it's running at 50 MHz and on the 8500 it's running at 40 MHz. The 9500's
video is on a regular PCI bus that runs at 33 MHz."

The just-released PowerMac 7200 and 7500 are very appealing. (The 8500 and 9500
seem overpriced.) All the PCI Macs have two busses: the PCI bus always runs at a
fixed 33 1/3 MHz; the processor bus runs from 40 to 50 MHz, depending on the
model or CPU card (Noah Price, [e-mail]). The 7200 is quite similar to the
7500, having lower clock rate, lower internal SCSI speed, and non-upgradable
soldered-in processor chip. The functional difference between the 7500 and the
8500 seems to be just the processor, processor-bus speed, and L2 cache (7500/100
has 601 running at 100 MHz, 50 MHz internal bus, and L2 cache is optional;
8500/120 has 604 running at 120 MHz, 40 MHz internal bus, and L2 cache is
included). MacWeek reported that moving the 604 daughterboard and the L2 cache
from an 8500 to a 7500 yielded the same performance. All the reviewers love the
case of the 7200 and 7500 (easy to access internals) and hate the 8500 minitower
case (requires extensive disassembly to add memory). Based on the those specs, I
think the best buy would be the 7200--add an L2 cache for more video
speed--closely followed by the 7500, with the 8500 seeming to be a lot more money
for very little more in performance. However, the benchmarks below reveal that
the 7500 video speed is significantly higher than all other Macs, presumably
because of its 50 MHz internal bus. Furthermore, an Apple engineer has offered to
produce custom versions of the 7500/8500 video driver to support high monitor
frame rates. I will share these with users of the VideoToolbox. Wanting to use
these custom drivers restricts me to just those two models, 7500 and 8500. I've
ordered four 7500's. I may upgrade to the 604 processor in the future, when it's
cheaper.

Ken Alexander, [e-mail], reported, and it's confirmed by Apple, that
the video driver on the 7500 and 8500 supresses the VBL interrupt while it's
loading the CLUT, so any VBL-interrupt-based task (e.g. a frame counter) will
miss a frame each time you call cscSetEntries to load the clut. Calling
cscSetEntries once per frame to synchronize your code with the display should
work fine, but it'll be slightly tricky to check for overrun (i.e. trying to do
too much between cscSetEntries calls), since a simple VBL-interrupt-based frame
counter will run differently on different Macs. I've just received
documentation on extra video driver calls, supported only by this driver, that
disable the interrupt suppression. See "7500/8500 driver.doc".

MacWeek 10/9/95 page 42 said that the powermac 7200's video speeds up with more
vram. As indicated in the table above, Tom Busey tried adding 1 MB of VRAM
(costing $85) to the standard 1 MB on his 7200/90, and found a 33% increase of
CopyBits speed.

Power Mac 7100 NuBus bug: Michael Eckert ([e-mail]) writes, "From
what I understand, a bug in the 7100's NuBus interface chip limits the throughput
of the NuBus port. This does not affect built-in VRAM video or DRAM video (the AV
option, in PDS slot). This bug affects only the 7100 (not 8100), and is supposed
to be fixed during the next release of the machines." October 12, 1994.

SPRITES. If you want to show objects moving around the screen, and your
computer isn't fast enough to do a full screen movie, then you may want to
animate just the objects. Objects animated in this way are called "sprites".
Tony Myles has published a package called "SpriteWorld" that you may want to
download from info-mac/Development. (For an explanation of how to do that, read
the VideoToolbox "Advice" document.)

PAGE SWITCHING. Many video cards have multiple video pages; check your
TimeVideo report, or call GDGetPageCnt(). Normally the Macintosh only uses page
0, but if you have multiple pages, they can be switched by calling
GDSetPageShown() and GDSetPageDrawn(). This could be used to show very short
full-screen movies, e.g. alternating two images. This might be an effective way
to show large slow movies, taking several frames to load each new image to an
unseen page that's instantly swapped in when it's full.  (The number of pages
available depends on the pixel size. In max depth there's always only one page.
In lesser depths there's unused memory, which the video driver may make available
as extra pages.) Sergei A.Kurkin, [e-mail], has "tested
GDSetPageDrawn() and GDSetPageShown(), and they seem to work OK."

CLUT (Color Lookup Table) ANIMATION. Most video cards have a hardware color
lookup table (clut) that dynamically transforms each pixel to a color (an RGB
triplet) that is sent to the digital to analog converters. Temporal modulation
(e.g. flicker or fading on and off) of visual stimuli can be achieved very
conveniently by loading a new clut on each frame. Look at the demo
FlickeringGrating. However, not all video card drivers are fast enough to
achieve this. (Usually this is not a hardware limitation; it's crumby driver
software.) Run TimeVideo to find out for sure; it determines how many frames it
takes either GDSetEntries or SetEntriesQuickly to load the clut. The clut is
also used for gamma correction. Apple's provision for gamma correction is
somewhat crude; for the utmost luminance accuracy you may wish to use the
Luminance.c routines. See section B, below.

COLOR CYCLING. Bart Farell, [e-mail], writes, "It's easy to do
color cycling using either GDSetEntries or SetEntriesQuickly, e.g.
    GDSetEntries(device,start,count,table+offset);
First create a double-sized ColorSpec array, e.g., an array of 512 instead of
256. It's called "table" in the above example. Set up the second half of the
array to be identical to the first half, to implement wrap-around.
GDSetEntries/SetEntriesQuickly(), as always, loads “count+1” entries starting at
entry “start”. (Yes, “count+1”, that’s Apple’s confusing convention.)  Just add
an integer "offset" to the table pointer. GDSetEntries/SetEntriesQuickly() will
start reading the table, offset by that number of ColorSpecs. Across a sequence
of frames, using a different offset for each call to GDSetEntries or
SetEntriesQuickly(), each ColorSpec of the array can be loaded to any entry. In
practice you'd create several of these double-sized ColorSpec arrays and animate
by using a different array and offset on each frame.  The payoff is that the
number of arrays, and clut computation time, is an order of magnitude lower than
would be required to compute a custom clut for each case."

MAKING DYNAMIC WHITE NOISE. I know of at least three people (including myself)
that hit upon clut animation as a fast way to synthesize dynamic white noise.
You fill the image plane with random numbers in the range 0 to 255, and you
load a new random clut on each frame. It might seem that this will produce noise
that is spatially and temporally uncorrelated. Not quite. Any pair of pixels has
a 1/256 chance of being driven by the same clut entry, in which case they will be
perfectly correlated. So the spatial autocorrelation function has the (desired)
delta function at zero separation and an (undesired) 1/256 correlation at all
other separations. This corresponds to the desired flat spectrum, PLUS an
undesired delta function at zero spatial frequency. In plain English, you'll end
up with dynamic white noise plus a spatially-uniform temporally-white flicker.
(This problem does not arise if you only use each clut entry once, but that
restricts you to an image of only 16x16.) Note that I am only discussing first
and second order statistics. Higher-order statistics will still differ from truly
white noise, but I doubt that our visual systems are sensitive to the difference.
However, the spatially uniform flicker component of the clut animation noise is
visually very salient. Ted Adelson noticed it immediately when I proudly
demonstrated this method at Optical Society in San Francisco in 1989 (I think).
The artifactual flicker becomes progressively more salient as you increase the
viewing distance, since the spatially uncorrelated noise fades out while the
spatially uniform noise is unaffected. What I now do, and recommend to others, is
to use brute force. Precompute all the noise and show a movie in which all the
pixels are truly independent random samples. The VideoToolbox routine RandFill()
is a fast way to compute the noise, and is used by NoiseFill.c. Try the demos
Sandstorm and NoiseVBL.

FANCIER TRICKS. The video card has only one clut, but it is possible to
simultaneously present multiple independently modulated patterns, by reserving
separate sections of the clut for each temporal modulation, though you'll
suffer a comensurate loss of intensity resolution. Clut animation is not
restricted to dynamic modulation of contrast. If the pixel values represent
phase, and the clut is loaded with a sin function, then rotating the clut
entries--i.e. setting the i-th entry to what was formerly the value of the i-1
entry (see Color Cycling, above)--will shift the phase of the pattern. A
spatially vignetted drifting grating may be synthesized by using alternate pixels
(or frames) to represent vignetted sin and cos components of the pattern,
devoting half the clut to each (or loading alternate cluts on alternate frames).
Appropriate adjustment of the relative contrasts of the sin and cos components
will produce any desired phase of the sum. However, most of these tricks are
superfluous; it’s usually easier and better to just show a movie. Many current
processors are fast enough to show 8-bit full-screen movies.

A. HOW TO SYNCHRONIZE A MACINTOSH PROGRAM TO A VIDEO CARD.

The hardest part in doing vision experiments is synchronizing the computer
program to the video card. Nearly all video cards are masters, and run freely,
expecting the video monitor to be a slave. Any experiment that cares about
timing will normally have to synchronize itself to the video card, by waiting
for each frame to end, as will be discussed below.

You typically can't access the video card hardware directly, because it's
undocumented. Instead you are allowed to send requests to the video driver
associated with your video card. All video cards that plug into the Mac come
with video drivers that conform sufficiently well to the Apple guidelines that
they are at least minimally compatible with the VideoToolbox. However, some
drivers have outright bugs, and the timing of many drivers, for which Apple
does not publish guidelines, sometimes makes it surprisingly difficult to do
simple things. A current list of these bugs and "features" appears in the
VideoToolbox "Video driver bugs" document.

Every video card has a video driver in its ROM, but the manufacturer may supply
a newer driver by floppy that supercedes the one in ROM, which may be buggy.
(Built-in video devices, e.g. in the Mac IIci and Quadra computers, load the
video driver from the computer's ROM.) Apple distributes video driver updates
as resources in the System file, so updating your System may change the video
driver of your Apple video card. IdentifyVideo(device) returns a string with the
name and version number of the driver that is actually in use. Try TimeVideo.

There are three different ways to synchronize a program to a video card, which
we'll first describe quickly, and then more fully. (1) Apple recommends using
the vertical blanking interrupts, which are supposed to occur once per frame,
at the beginning of the vertical blanking. The VideoToolbox VBLInstall.c routines
make this very easy to do. A disadvantage of this approach is that it fails if
you raise the processor priority to block all interrupts. (2) Most (not all)
video drivers, when asked to load the clut, wait until the vertical blanking
interval before beginning to load the clut. (They wait in order to avoid creating
visible hash on the screen while the clut is changing.) This has the side effect
of synchronizing your program to the display, since the driver doesn't return
control until the VBL interval occurs. Either of these synchronization methods (1
or 2) may fail, depending on which video card you have, what you've set the pixel
size to (1 to 32 bits), and whether you've raised the processor priority. The
demo program TimeVideo tests both methods of synchronization on all your video
cards at all pixel sizes and saves the results in a text file. (3) I think that
all video cards provide a read-only vertical-blanking bit, but unfortunately few
manufacturers will tell you its address, so you have to find it yourself
(typically by disassembling the video driver), which is tedious.

1. VBL Interrupts. Most video cards emit one VBL interrupt during each video
frame. However, during 1990-1 Apple generated some poor video drivers for their
cards ("Macintosh Display Card": 8•24)  and the built-in video in the Quadra 700
and 950. These drivers generate several interrupts per frame. (Kyle Cave
discovered that there are no extra interrupts if the cache is disabled on the
Quadra 700.) This behavior is contrary to Apple's documentation, but VBLInstall.c
works around the bug, using a timer to discard the excess interrupts (as
suggested by Raynald Comtois). Some video drivers take multiple frames to load
the clut, and block interrupts while doing so, wreaking havoc with any attempt to
count frames. Apple's video drivers produced before 1990 and since 1992 seem to
be ok. (This may be in response to my many bug reports.) Try the demos TimeVideo
and NoiseVBL.
     The best current theory (due to Raynald Comtois) on the source of the
extra interrupts is that the card is asserting the interrupt line for a fixed
duration, perhaps 1 ms. As long as you are in the interrupt-handling routine (or
one of higher priority), other interrupts of the same level are disabled. If you
stay in the interrupt routine for long enough, the interrupt line has time to be
released and you don't get a second interrupt, otherwise you do.

2. LOADING THE CLUT. It seems that all video drivers automatically synchronize
clut-loading to the video frame. Apple's guidelines for video drivers (in the
book Designing Cards and Drivers) state that the video driver may save the
clut-load (i.e. cscSetEntries) request and defer the actual loading until the
next VBL interrupt. Such video drivers return almost immediately after a
cscSetEntries request. Thus, although the actual clut load will be synchronized to
the display, your program will be asynchronous because the GDSetEntries call will
return immediately. However, Apple's guidelines state that if the processor's
interrupt priority has been raised, suspending the video card's VBL interrupts,
then the video driver should always load the clut before returning, which would
synchronize your program to the display. You can raise and lower the processor
priority by calling the VideoToolbox routine SetPriority.c. The priority is
normally zero. TimeVideo measures timing at both normal and high psiority.
     Be aware that a cscSetEntries request, i.e. calling GDSetEntries(), does not
necessarily wait for the beginning of the next vertical blanking interval. It
might merely wait until blanking is true. As a result, two successive GDSetEntries
calls might occur during the same blanking interval. To get exactly one call per
frame you may need to delay for a suitable interval (perhaps 1 ms) before calling
it again.
     Most video drivers that I've tested seem to be synchronous and reliably
take exactly one frame to load the clut. However, some video drivers take
longer, e.g. any loading of the clut on Apple's new video cards ("Macintosh
Display Card": 8•24) takes 30 ms--two frames--which is unacceptably slow for
lookup table animation. The TrueVision NuVista seems to be asynchronous.
Presumably the on-board processor accepts the clut information at any time and
actually updates the clut during the next vertical blanking interval. However,
this means that asking the video driver to load the clut doesn't have the
useful side effect of synchronizing the Mac program to the display. The NuVista
takes about 0.3 frames (i.e. a few ms) to reload the whole clut when in 8, 16, or
32-bit mode, but takes several frames (i.e. tens of ms) when in 1, 2, or 4-bit
mode (presumably because the fractional byte addressing is slow). I haven't
checked, but presumably the NuVista driver would become synchronous, as specified
by Apple, if the processor priority were raised.
     SetEntriesQuickly.c--written primarily by Raynald Comtois, Peter Lennie,
and Bill Haake--provides fast clut loading for several popular video devices. Try
TimeVideo.
     If 8-bit pixels are enough, and you have a NuBus, consider buying Apple's
old "Toby" or "TFB" video cards, since they work fine, and cost only $90 each
from Shreve Systems (800)-227-3971.

3. BLANKING BIT. Apparently all video cards have a blanking bit (telling
whether the video signal is in the blank period between frames), but, alas, the
manufacturers never tell you where it is. You could figure out which bit by
disassembling the driver, as I did for the Apple Toby and TFB video cards (no
longer sold by Apple; call Shreve at phone  number given above). Perhaps one
could write a program that would find the VBL bit automatically, by looking for
any bit that changes at the right frequency.
     WaitForBlanking() in SetEntriesQuickly.c tests the blanking bit, but
presently supports only the (obsolete) Toby and TFB video cards. Hopefully other
people will enhance this routine to support more devices.

4. CONCLUSION. Don't take synchronization or lookup table animation for granted.
Run TimeVideo to check out your video cards.

B. SYNCHING MULTIPLE VIDEO CARDS TO EACH OTHER

SOFTWARE: Short of butchering the hardware, synching two video cards is hard to
do. It needn't be so, if the manufacturers were more forthcoming about how to
program their cards. By disassembling the video driver for Apple's original
"Toby" video cards I worked out that there are halt and restart commands that can
be issued to the card. Several video cards can be synched by restarting them all
at once (actually one after the other, in quick succession). Their quartz
crystals run at slightly different frequencies so the cards slowly drift out of
phase with each other, but that's still good enough for a relatively brief visual
stimulus, resynching before each stimulus. Software to do this for the Toby video
cards (which are still available from Shreve Systems (800)-227-3971, $90 each) is
in the VideoTFB.c file in the VideoToolbox. It seems very likely that this
approach is applicable to most video cards, but you would need to discover what
the appropriate commands are to restart your cards. (Normally, video cards are
restarted only at system restart.) You might be able to do this by disassembling
the video drivers, but perhaps the manufacturer would tell you if you asked
nicely. (Incidentally, the "Toby" video cards also have an undocumented ribbon
cable connector that an Apple engineer explained to me could be used to achieve
hardware-level synchronization. He said it might not work. I tried, but never got
it to work.) I hope you'll share any useful results with me. I'd love to learn
the restart commands for other video cards, especially Apple's, and would add
support for them to the VideoToolbox software.

HARDWARE: David Brainard <[e-mail]> writes, "We have been
working on the problem of synchronizing two video cards. For the Apple 8•24 card
(rev B), we have a simple hardward solution. It turns out you can cut the clock
trace and push the clock signal through a fast OR gate. Somewhat to my surprise,
you can hold the clock for as long as you like without changing the state of the
board.  When you release the clock, the sync is shifted by the amount of time you
held the clock. The 8•24 cards are OK.  They will drive a 16" monitor and
SetEntriesQuickly works fast. They cost $239 used. There may be a software
solution like the one you developed for the Toby cards, but my guy struggled with
it for a while and gave up. (He is better with hardware than software, which is
why we went the way we did.)"
    Karsten S. Weber ( [e-mail]) adds, "I am working as a
programmer for Professor Martin Banks at the University of California at
Berkeley. We have recently done some stereo motion experiments that required
synchronizing two video cards. I read in the 'Video Tool Box documentation'
about how Dr. Brainard had developed a hardware solution for synchronizing two
8*24 cards. I have since used Brainard's work (and corresponded with him
frequently) to do the same for our lab, but we did have some troubles with his
approach primarily because we are using larger monitors. These problems have
been solved in a nice way, as described below.
    First I tried the approach that Brainard had successfully implemented
earlier, i.e. a transistor to stop the clock of the video board. After soldering
the transistor on the board, I tested it, and it worked fine. There is, however,
a problem with this approach. It only works for 13" and 16" monitors. When I
started using our 21" monitors, stopping the clock had no effect on the video
output whatsoever! There is more than one clock on the video board, and it turns
out that 21" monitors can be synchronized by stopping the fastest of the clocks.
Using the 21" monitor and the 8*24 video board gives a maximum of 256 colors.
    Secondly I implemented a nice software approach to synchronize the
monitors. By looking at the VBLs for both boards I saw that they only stay in
sync for a few seconds. This means that it is necessary to synchronize the video
boards before every trial, of which there can be hundreds. It is therefore
desirable to have a fast and easy way  to synchronize the boards. I came up with
a way for doing the synchronization that does not require photometers and a scope
(as is required in Dr. Brainard's approach). The idea is the following: The
hardware modification is installed on both video boards (rather than just one). A
VBL interrupt routine is written for each board. When a VBL occurs on the left
video board, the left interrupt routine is activated, and this routine stops the
clock for the left video board (it does this by controlling the hardware that was
added on the board). This means that the video board is stopped exactly at VBL
time. The same procedure is done with the right video board:  The interrupt from
the right video board activated the right interrupt routine that stops the right
video board. In this way both video boards get stopped at the time as their
respective VBLs. The main program is still running and when it detects that both
video cards have stopped, it activates them simultaneously, and the two video
boards are now in synch.  This means that synchronization can be done by calling
one function, and the time it takes to synchronize the video boards is less than
the time between the two VBLs. I'm using DTR of the modem and printer port to
control the hardware."

BB. MORE ON INTERRUPTS

Michael Bach, [e-mail], writes, "We are trying to do
simultaneous visual stimulation and analog measurement of brain potentials on
the same Macintosh. One of our ideas was to use the Time Manager to trigger
analog measurement every 2 ms in its interrupt service routine. This works fine
unless we use animate palette (or GDSetEntries or GDSetGamma): No timer tasks
are serviced until vbl. Apparently the video driver goes into a tight loop,
polling a vbl flag, with interrupts switched off! Can this be true? This would
be a strong setback for using the Mac for this sort of work." Yes, alas, the
normal behavior for interrupt service routines and the driver Control calls on
the Mac is to suspend all interrupts until returning. Most video card drivers
wait for vbl, as Michael says. However, TrueVision's NuVista returns
immediately, letting the video card processor do the work later, at vbl time.
And SetEntriesQuickly.c, for the few devices that it supports, allows you to
achieve whatever behavior you want. Those solutions will make your code highly
dependent on the particular video card. One solution that might work on all
video cards would be to only call the video driver (e.g. GDSetEnries) during
vertical blanking, i.e. immediately after the vbl interrupt occurs (use
VBLInstall.c).
     Michael Bach ([e-mail]) adds, "We have since done
more experiments. We have an A/D card from National Instruments (NB-MIO-16),
which we use with LabView. National Instruments also provide a library of
lower-level routines ("NI-DAQ"), namely one "SCAN" that regularly scans analog
input and writes into a buffer in memory. As the card lacks DMA, this is --
reading between the lines of their documentation -- implemented by an interrupt
service routine called at the end of conversion. For this, the "NB-Handler Init"
must be installed when the system is started up. While interrupts are blocked,
measurements are kept in a FIFO on the card. If we use their SCAN routine,
sampling is performed smoothly and not blocked by AnimatePalette et al.  But care
has to be taken that the FIFO is not overrun." This confirms that the video
driver blocks all interrupts. Any interrupt that's still asserted will occur when
the video driver exits. The timer interrupt is asserted only briefly and is lost
if not serviced promptly; apparently the A/D card's slot interrupt request
remains asserted until serviced.

C. CONTROLLING THE COLOR LOOKUP TABLE (CLUT)

QuickDraw is one of the great virtues of the Macintosh. However, several of its
assumptions about what you want are inappropriate for vision experiments. In
particular, it assumes that you want all your monitors to act as one consistent
desktop (with consistent color tables). This is a problem if you want to load
completely independent lookup tables and images onto two monitors that, for
example, you may want to superimpose optically. QuickDraw enforces the
consistency throught the Palette Manager, but calls that are nominally to the
Color Manager (e.g. Apple's SetEntries) may be intercepted by the Palette
Manager, resulting in undesired effects on other screens. My solution is to
bypass QuickDraw and to load the lookup tables more or less directly, without
telling QuickDraw.

GDSetEntries() and SetEntriesQuickly() work outside of QuickDraw. GDSetEntries
makes a cscSetEntries control call to the video driver; SetEntriesQuickly
directly addresses the hardware. They both load the clut of the video card
without changing the color spec table of the graphics device; QuickDraw will
continue to assume that the graphics device's color spec table is a true copy of
the clut. This is the behavior that I usually want. However, it may cause
problems if you use CopyBits since CopyBits will translate the color of each
pixel it copies, using the inverse color table of the current device, which is
based on the color spec table, NOT the clut. If you want to use CopyBits or
SetCPixel, you should copy your color spec table into the graphics device's color
spec table, and set ctSeed to alert QuickDraw that it's been changed. Or, instead
of using QuickDraw's CopyBits and SetCPixel, you could use the VideoToolbox's
CopyBitsQuickly and SetPixelsQuickly(), which copy pixel walues directly,
ignoring all color tables and inverse color tables.

D. HIGH FRAME RATES

On March 17 fifty of us sent a letter to Apple--see "cscSetModeTiming.doc" in the
"Notes" folder--requesting a new feature for video drivers to support arbitrary
frame rates and resolutions. High frame rates are particularly relevant to stereo
(using LCD glasses to alternate eyes) and retinal physiology (because retinal
ganglion cells respond up to 100 Hz).

For some vision experiments it is desirable to run at very high frame rates, e.g.
100 or even 200 Hz for retinal physiology experiments. There exist special
monitors, e.g. the Joyce DM-4 Display, that run at such high frame rates, but no
video cards automatically configure themselves to work with such odd displays.
All Mac video cards that I know of are programmable to a wide range of line and
frame rates, but very few video card manufacturers provide information on how to
do this programming. (Normally, the video card senses the kind of monitor through
the monitor sense lines and the video driver programs the card to suit the
monitor. Alas, the monitor sense line scheme basically only identifies the Apple
monitors, and is not a general purpose solution. The video driver is a program
that is read from your video card's ROM into memory when you boot the computer.)
Truevision does supply information on how to program the NuVista to arbitrary
line and frame rates. (I believe the TrueVision's max frame rate is over 100 Hz,
but I don't recall what the limit is.)

Apple's response has two parts. Firstly, the VideoToolbox now includes a custom
version of the video driver for the PowerMac 7500/8500 (sorry it's ONLY for those
two models) that supports a 120 Hz frame rate at 640x480 pixels. This custom
version was created for us by Fernando Urbina, the Apple engineer who wrote the
original 7500/8500 built-in-video driver. Secondly, he is trying to draft a spec
to allow a general-purpose video driver call that would allow us to specify any
achievable configuration of pixels and frame rates.

E. MORE-THAN-8 BIT DACs

NuBus cards:
RasterOps “ProColor 32” has 9-bit DACs.
RasterOps “Paintboard Turbo XL” has 9-bit DACs. $1399 (Mentioned by Steve Shevell)
Radius Thunder IV GX-1600,-1360,-1152 and Thunder/24 GT have 10-bit DACs & 185 MHz pixel clock.

Rhea Eskew, [e-mail], writes "There is a 12-bit video board now available
for the Mac. It's the Psychophysics Display Interface, from Australia. I have the
generation 2 version, and Charles Stromeyer has purchased generation 3, which is
now in my lab (but hasn't yet really been tested).  In addition to 12-bit dacs it
has some nice hardware features, like configurable color lookup tables and 2
frame buffers (you can allegedly make one image a function of another, like for
windowing etc -- but I haven't tried it yet).  The drawbacks are the cost (I
don't know how much he'll charge now, but it's at least 8X the cost of a standard
board) and the fact that the maker is small, in Australia, and has had trouble
delivering new products according to schedule (he has been prompt and helpful
about solving problems after delivery, however)".
James Sokoll Pty Ltd
PO Box 808
Kenmore  4069 AUSTRALIA
Tel: [phone]
Fax: [phone]

Does anyone know of any others?

F. SHIELDCURSOR

In the summer of '93 Steve Lemke at Radius ([e-mail]) wrote, "Apple has
stated several times (though I wouldn't necessarily expect you to have run across
any of them) that if you write directly to the screen, you must use the
"ShieldCursor" and "ShowCursor" traps to prevent the cursor from being
overwritten.  To do so, you pass the rectangle in which you are drawing to
"ShieldCursor". It's nice that all QuickDraw routines use this trap, as it makes
for a simple way to identify what areas of the screen are changing. It also makes
for a simple way for people who draw directly to the screen to notify the Radius
PowerView software that they are doing so.  Everything in that rectangle gets
updated on the Radius PowerView screen.  Too bad more programs don't use it,
though..."

Taking his advice, CopyWindows calls ShieldCursor before calling
CopyBitsQuickly.

G. DISASSEMBLING A VIDEO DRIVER

Assuming you can read 680x0 assembly code, use the VideoToolbox utility
GrabVideoDrivers to put the driver into a file, then use ResEdit with the
ResEdit CODE editor to examine it, comparing it with the example in the
appendix of Apple's Designing Cards and Drivers book. The ResEdit CODE editor is
a public domain file distributed by:
Ira L. Ruben
Apple Computer, Ioc.
20525 Mariani Ave., MS: 37-A
Cupertino, Ca. 95014
[e-mail]
ftp.apple.com:/dts/mac/tools/resedit/resedit-2-1-code-editor...

H. FIXING THE MAC IIci BUILT-IN VIDEO DRIVER

(The following remedies worked for the Mac IIci video driver, patching or
replacing the buggy version 0 .Display_Video_Apple_RBV1 driver by copying the
bug-free version 1 of the same driver from the Mac IIsi. It is very likely that
an analogous approach could be used to patch or replace the buggy version 0, 1,
and 2 .Display_Video_Apple_DAFB drivers in the Quadra 700, 750, and 900, by the
bug-free version 3 or 5 of that driver in the Centris 650 or LC 475.)

The Mac IIci built-in video driver (.Display_Video_Apple_RBV1 driver, version 0)
has a bug that causes it to crash if you try to do a cscGetEntries Status
request. Here are two ways to fix the bug:

1. AUTOMATIC TEMPORARY PATCH. (This happens automatically if you use GDVideo.
This note is an explanation, in case you're curious.) The bug only affects
GDGetEntries, so the first time GDGetEntries is invoked it automatically calls
PatchMacIIciVideoDriver() in GDVideo.c to find and patch the copy of the buggy
driver residing in memory, preventing any trouble. (If the driver is in ROM, then
the driver is copied to RAM, and patched there.) Only two instructions are
modified, to save & restore more registers. (I figured out what needed patching
by comparing this driver's disassembly with the bug-free version in the Mac
IIsi.) And the driver's version number is changed from 0 to 100, so that programs
can distinguish it from the buggy version 0. This fix persists only until the
next reboot.

2. PERMANENT UPGRADE. The Mac IIsi has version 1 of the same driver, without
the bug. In principle all you have to do is copy the new driver from the IIsi
to your IIci, but this is nontrivial because these drivers are in ROM. It is
fairly simple, as described below, to place a copy of the version 1 (i.e.
fixed) driver into the System file of the Mac IIci, but, as explained in Inside
Mac V-424, this will only displace the older version 0 (buggy) driver if it's
not driving the boot monitor (i.e. if the "Welcome to Macintosh" message
appears on some other monitor), because the boot monitor's driver is loaded at
boot time before the System file is available. If you have multiple monitors,
you can use the Monitors Control Panel to change the boot monitor: hold the
option key down and drag the smiling Mac to any monitor except the one driven
by the built-in video. So, in case you do have multiple monitors, here's how to
copy the driver. First put the VideoToolbox utility "GetVideoDrivers" on a
floppy and run it on a Mac IIsi. That will copy the all the video drivers onto
your floppy as ResEdit files. Then put the floppy in your Mac IIci and copy
"-Display_Video_Apple_RBV1" onto your hard disk. Make a copy of your System
file. Open the "-Display_Video_Apple_RBV1" file in ResEdit. Hit Command-I to
edit the Resource Info. Set the "System Heap" and "Purgeable" flags, change the
ID from 1 to 122, and close the Resource Info window. Now copy the resource and
paste it into the copy of your System file. Quit, saving changes. Now rename
the active System file to something else, like "old System", and rename the
edited System file to "System". Reboot. You can now throw the old System into
the trash. The new driver will automatically be favored over the one in ROM
because it has a higher version number (1 instead of 0). All my test programs
indicate that the new driver works fine in the Mac IIci with System 7, and I
would expect it to work fine with System 6 as well. (Thanks to
[e-mail] for figuring out why it didn't work for the boot
monitor.)

I. VIDEO BANDWIDTH
Paul Sowden, [e-mail], asks, "We have built a video attenuator for
use with a PC based system and are now at the stage of calibrating our
attenuator. Prior to this we need to check the input impedance of our monitor
at various frequencies in the manner you describe in your paper (Vis. Res. 31,
1337-1350). In your paper you state that Z (the monitor's input impedance)
should be independent of the oscillator frequency, from d.c. to 20 MHz. Our
query is where does the upper limit of 20 MHz come from?" Sorry, the paper
should have spelled it out. Your monitor draws pixels one after another along
each scan line as it paints your image on the screen. The clock rate of the
pixels depends on your video card. 20 MHz was common at the time the paper was
written (e.g. a 640x480x67 Hz display) but higher speeds, e.g. 100 MHz, are
common now. If you think about the spatial frequency spectrum of a scan line,
it corresponds to the temporal frequency spectrum of the video signal for that
line, where the width of the screen (e.g. in degrees of arc at the viewer's
eye) corresponds to the time for the line to sweep across the screen. The time
for a line is approximately the reciprocal of the line rate (except for a small
blanking interval), which is typically around 34 kHz. (Alternatively, and
equivalently, you can establish the correspondence based on a pixel's width and
its duration, which is the reciprocal of the pixel clock rate.) If the pixel
clock rate is f, then a scan line can represent image frequencies up to f/2 (by
the Nyquist sampling theorem), and you would want the monitor's input impedance
to be constant up to at least that frequency. In practice the only way of
achieving this is to design a high-input-impedance amplifier with a 75 ohm
resistor at its input. That gives the desired fixed impedance over a very wide
bandwidth. So, in practice you'll probably find that your monitor's input
impedance is either terribly frequency dependent (and unfit for serious
psychophysical work) or fine over a very wide bandwidth. A separate issue is
that it is desirable for the video bandwidth of the monitor to be as high as
possible, to follow the frequencies in the incoming video signal, to avoiding
nonlinear distortions from slew rate limitations, as discussed in the paper.

VIDEO BUGS

Other than reading and writing pixels, all access to a video device normally
goes through the software video driver. (You can use VideoToolbox
SetEntriesQuickly.c to bypass the video driver of a few devices, but I don't
recommend that, except as a last resort, because your program will then only
work with the few video devices that SetEntriesQuickly supports.) The video
driver is normally supplied in ROM on the video card or, for built-in video, in
the computer's ROM. (Apparently, new PCI drivers can simply be tossed onto the
System Folder.) Many drivers have subtle bugs that TimeVideo has uncovered and
documented. This file is a complete list of all the bugs that I know of. I have
the very strong impression that reporting these bugs to the manufacturers has
led them to eliminate the bugs in subsequent versions. Before TimeVideo there
was no easy way to test for most of these bugs. If your driver is not listed,
please run TimeVideo and send me the report: [e-mail]

1. The following drivers crash if one attempts to make a cscGetEntries request.
GDGetEntries tests for these driver names and version numbers, and returns an
error message instead of calling a driver that would crash. Try the demo
TestGDVideo.
•Mac IIci “Macintosh II Built-In Video” (.Display_Video_Apple_RBV1) (Reported
to Apple MacDTS 3/7/90 and Apple.Bugs 12/30/92)
•Relax 19" Model 200 (.Color_Video_Display version 9288). (Reported to Relax
Tech. 1/19/93)
•DOME MD Max (.Display_Video_Apple_DOMEMax version 2). (Reported to DOME
3/30/95.)

2. The following drivers either take too long (more than 1 frame) to load the
clut (i.e.  cscSetEntries), or suppress one or more frame's worth of VBL
interrupts each time they load the clut, or both. Try TimeVideo.
•Apple Power Macintosh 8500/120 (.Display_Video_Apple_Control) each call to
cscSetEntries suppresses 1 vbl interrupt.
•Apple 4•8 and 8•24 “Macintosh Display Card” (.Display_Video_Apple_MDC) and
“Macintosh Display Card 8•24 GC” (.Display_Video_Apple_MDCGC) take two frames
to load the clut (and suppress one vbl interrupt) in all modes. (Reported to
Apple.Bugs 12/30/92)
•Radius PrecisionColor 8  and 8xj take 5-8 frames to load the whole clut in
8-bit mode (and suppress 5-8 vbl interrupts); the time is proportional to the
number of clut entries being loaded. (Ok in 1-, 2-, and 4-bit modes.)
•“RasterOps ColorBoard 264” (.RasterOps 1.2 264   Video Driver version 9327)
takes 2 frames to load the clut (and suppresses 1 vbl interrupt) in 8- and
32-bit modes. (Ok in 1-, 2-, and 4-bit modes.)
•RasterOps  “PaintBoard Li” 1.0 24XLi Video Driver takes 4 frames to load the
clut (and suppresses 3 vbl interrupts)  in 8-,16-, and 32-bit modes. (Ok in
1-,2-, and 4-bit modes.) (Reported to RasterOps 12/30/92).
•“RasterOps 8XL” (.RasterOps 1.2 8XL Video Driver version 9327) takes 4 frames
to load the clut (and suppresses 3 vbl interrupts) in 8-bit mode. (Ok in 1-,2-,
and 4-bit modes.)
•"RasterOps 24XLTV" (.RasterOps 1.4 24XLTV Video Driver version 9327) takes 4
frames to load the clut (and suppresses 3 vbl interrupts) in 8- and 32-bit
modes. (Ok in 1-,2-, 4-, and 16-bit modes.)
•RasterOps "PaintBoard Turbo XL" (.RasterOps 1.0 PBTurboXL Video Driver version
9327) takes 4 frames to load the clut (and suppresses 3 vbl interrupts).
•“Spectrum/8•24 PDQ” (.Display_Video_Apple_SpecRice version 3) takes 4 frames
to load the clut in all modes.

3. The following cards and drivers issue multiple VBL interrupts per frame,
whereas they should emit exactly one per frame. Try TimeVideo.
•The 4•8 and 8•24 “Macintosh Display Card” (.Display_Video_Apple_MDC) emit
several VBL interrupts per video frame. (Reported to Apple.Bugs 12/30/92)
•Apple Quadra 700 "Macintosh E Built-In Video" (.Display_Video_Apple_DAFB)
emits 2 VBL interrupts per frame if the processor cache is enabled, but emits
only 1, as it's supposed to, if the processor cache is disabled. (Reported by
Kyle Cave, [e-mail])
•Apple Quadra 900 “Macintosh C Built-In Video” (.Display_Video_Apple_DAFB)
occasionally emits more than 1 VBL interrupt per frame.
•Apple Quadra 950 “Macintosh G Built-In Video” (.Display_Video_Apple_DAFB
version 2)  emits 2 or 3 VBL interrupts per frame. (Reported to Apple.Bugs
12/30/92)
•Note that the .Display_Video_Apple_DAFB version 3 driver does NOT exhibit this
bug, at least on the Centris 650 where it resides. It would be interesting to
try copying this driver to the afflicted Quadra's, adapting the instructions
given above for copying a driver from the IIsi to the IIci.

4. 16 & 32-bit modes. These video drivers will correctly load the whole clut,
but screw up if asked to load one clut entry at a time. The problems only occur
in 16- and 32-bit mode, i.e. calling cscDirectSetEntries. Apparently few or no
applications (other than TimeVideo) ever do this, as otherwise the
manufacturers would have detected the fault.
•TrueVision NuVista version 3.0 cscDirectSetEntries (i.e. 16- and 32-bit pixel
modes) loads garbage unless “start” is zero. cscSetEntries (i.e. 1-, 2-, 4-,
and 8-bit pixel modes) works fine.
•RasterOps "PaintBoard Turbo XL" (.RasterOps 1.0 PBTurboXL Video Driver version
9327) crashes when attempting to serially load the CLUT in 16-bit mode.

5. The following video drivers don't support cscSetGamma or cscGetGamma.
(Apparently Apple considers these calls are optional, so not supporting them is
not, strictly speaking, a bug.)
•“Radius PowerView” (.Radius PowerView Display version 9848) calling
cscGetGamma returns a gamma table that's all zero. Calling cscSetGamma has no
effect. Fortunately the permanent gamma table is the identity transformation.
(Radius confirmed the bugs on 7/93.)
•“Radius GS/C” (.Radius GSC version 18663) doesn't support cscSetGamma or
cscGetGamma. Unfortunately the permanent gamma table is NOT the identity
transformation, so it fails the write-then-read cscSetEntries-cscGetEntries
test performed by TimeVideo. (Radius suggests upgrading to one of their newer
cards. 3/95)
•“SuperMac ColorCard” v1.97S (.Display_SuperMac_ColorCard version 1) does not
implement the gamma table; cscSetGamma and cscGetGamma both return error codes.
Fortunately the permanent gamma table is the identity transformation.

6. Some color video cards autodetect monochrome monitors, and remain in gray
mode despite attempts to set to color mode (e.g. to use the ISR Video
Attenuator). You may be able to fool the video card into thinking it's driving
a color monitor by using a MacLiberty adapter [cheap--ordering address appears
in "Advice"] to program the sense pins appropriately.
•If the “Radius PrecisionColor 8” and “Radius PrecisionColor 8Xj” sense a
monochrome monitor then they always operate in "gray" mode, even though the
driver allows you to set and read the color/gray bit. Try TimeVideo.
•Tom Busey asks, "I have an apple 2-page monochrome monitor, and I'd like to
use an ISR Video Attenuator with it [see VideoToolbox:ISR Video Attenuator].
The problem is that my PowerMac 7100 vram port insists that the 2-page monitor
is grayscale only, i.e. TimeVideo reports !color. Is there any way to trick the
card into thinking it is in color so that I can use my video attenuator?" A few
weeks later, he adds, “The MacLiberty adapter does fool the computer into
thinking I’ve got a color monitor. However, the monitor has an unusual
connector and takes its input from the blue instead of the green video pin, so
I'm making a custom  video attenuator with its output on that pin.”

7. Other bugs:
•“DOME Md Imaging Card” (.Display_Video_Apple_DOMEMd version 2) calling
cscGetEntries returns RRR instead of RGB. (Patrick Flanagan reported it to DOME
on 3/29/95.)
•“Spectrum/8•24 PDQ” (.Display_Video_Apple_SpecRice version 3) failed all
cscGetEntries tests when in 16-bit-pixel mode.
•“Truevision NuVista+™ Card” (.Display_Video_NuVista version ??) fails all
cscGetEntries tests. Reported by David Rose <[e-mail]> on 8/94.
•Relax 19" Model 200 (.Color_Video_Display version 9288) doesn't support the
optional cscGetGamma Status call. The required cscGetPageCnt (aka cscGetPages)
Status call erroneously returns a page count of 0 for all modes. Try TimeVideo
or TestGDVideo. (Reported to Relax Tech. 1/19/93)
•TrueVision NuVista version 3.0 can't display MacsBug.
•The presence of the 8•24GC accelerator seems to HALVE the speed of CopyBits,
at least on a RasterOps 8XL running on a Mac IIfx. CopyBitsQuickly is
unaffected, of course.
•Apple PowerBook 520/540 "CSC-2 Built-In Video" (.Display_Video_Apple_CSC
version 4) apparently makes small 1-2% errors in the write-then-read
cscSetEntries-cscGetEntries CLUT test performed by TimeVideo. (Perhaps it
doesn't support cscSetGamma.)

6. Video drivers that have been tested (v.0, unless noted otherwise):
Apple “Toby frame buffer card” (.Display_Video_Apple_TFB v.4,5,& 6)
Apple “Mac II High-Resolution Video Card” (.Display_Video_Apple_HRVC)
Apple 8•24 “Macintosh Display Card” (.Display_Video_Apple_MDC)
Apple “Macintosh Display Card 8•24 GC” (.Display_Video_Apple_MDCGC)
Apple Mac Plus “1-bit QuickDraw”
Apple Mac SE “1-bit QuickDraw”
Apple Mac Portable “1-bit QuickDraw”
Apple Mac Centris 610 “Macintosh I Built-In Video” (.Display_Video_Apple_DAFB v.3)
Apple Mac Centris 650 “Macintosh I Built-In Video” (.Display_Video_Apple_DAFB v.3)
Apple Mac Centris 660AV “Macintosh 3B” (.Display_Video_Apple_Civic)
Apple Mac Classic II “Macintosh F Built-In Video” (.Display_Video_Apple_Apollo)
Apple Macintosh LC III “Macintosh AA Built-In Video” (.Display_Video_Apple_Sonora)
Apple “Macintosh SE/30 Internal Video” (.Display_Video_Apple_MacSE/30 Video)
Apple Mac IIci “Macintosh II Built-In Video” (.Dksplay_Video_Apple_RBV1 v.0&1)
Apple Mac IIsi “Macintosh A Built-In Video” (.Display_Video_Apple_RBV1 v.1)
Apple Mac LC II “Macintosh B Built-In Video” (.Display_Video_Apple_V8)
Apple Mac LC 475 “MEMCjr Built-In Video” (.Display_Video_Apple_DAFB v.5)
Apple PowerBook 160 “Macintosh J Built-In Video”(.Display_Video_Apple_DBLite v.1)
Apple PowerBook 160 “Macintosh A External Video”(.Display_Video_Apple_ViSC)
Apple PowerBook 170 “Macintosh D Built-In Video” (.Display_Video_Apple_TIM)
Apple PowerBook 180 “Macintosh A External Video” (.Display_Video_Apple_ViSC)
Apple PowerBook 180 “Macintosh J Built-In Video” (.Display_Video_Apple_DBLite v.1)
Apple PowerBook 520/540 "CSC-2 Built-In Video" (.Display_Video_Apple_CSC v.4)
Apple Power Macintosh 6100/60 "Built-In VRAM Video"
Apple Power Macintosh 6100/60 "Built-In DRAM Video" (.Display_Video_Apple_Sonora v.3)
Apple Power Macintosh 6100/60av "Built-In AV Video" (.Display_Video_Apple_Civic v.1)
Apple Power Macintosh 7100/66 "Built-In VRAM Video" (.Display_Video_Apple_HPV_PDS v.1)
Apple Power Macintosh 7100/66 "Built-In DRAM Video" (.Display_Video_Apple_Sonora v.3)
Apple Power Macintosh 8100/80 "Built-In AV Video" (.Display_Video_Apple_Civic v.1)
Apple Power Macintosh 8100/80 "Built-In VRAM Video" (.Display_Video_Apple_HPV_PDS v.1)
Apple Power Macintosh 8100/80 "Built-In DRAM Video" (.Display_Video_Apple_Sonora v.2)
Apple Power Macintosh 7200 (.Display_Video_Apple_Platinum)
Apple Power Macintosh 8500/120 (.Display_Video_Apple_Control)
Apple Quadra 630 "Valkyrie Built-In Video" (.Display_Video_Apple_Valkyrie)
Apple Quadra 660AV "Macintosh 3B" (.Display_Video_Apple_Civic)
Apple Quadra 700 “Macintosh E Built-In Video” (.Display_Video_Apple_DAFB)
Apple Quadra 840AV “Macintosh 3A” (.Display_Video_Apple_Civic v.0&2)
Apple Quadra 900 "Macintosh C Built-In Video" (.Display_Video_Apple_DAFB)
Apple Quadra 950 “Macintosh G Built-In Video” (.Display_Video_Apple_DAFB v.1&2)
Apple WS 6150/66 “Built-In DRAM Video” (.Display_Video_Apple_Sonora v.4)
“DOME Md Imaging Card” (.Display_Video_Apple_DOMEMd v.2)
DOME MD Max "Vortech" (.Display_Video_Apple_DOMEMax v.2)
Ehman “15" Full Page Video Card...”(.Lapis DisplayServerT II Rev 1.0)
E-Machines "ColorLink_ SX-T" (.Display_Video_Apple_EM_10T v.5376)
Lapis “Dual Page Video 1024x768” (.Lapis DisplayServer™ II Rev 1.0)
“Radius GS/C” (.Radius GSC v.18663)
“Radius PowerView” (.Radius PowerView Display v.9848)
Radius PrecisionColor 8 (.Radius PrecisionColor 8)
“Radius PrecisionColor 8Xj” (.Radius PrecisionColor 8Xj)
“RasterOps ColorBoard 264” (.RasterOps 1.2 264   Video Driver v.9327)
RasterOps “PaintBoard Li” (.RasterOps 1.0 24XLi Video Driver v.9327)
RasterOps “ProColor 32” (.RasterOps 1.0 32XL Video Driver v.9327)
“RasterOps 8XL” (.RasterOps 1.2 8XL Video Driver v.9327)
RasterOps 24 L (.RasterOps 1.0 24 L Video Driver)
"RasterOps 24XLTV" (.RasterOps 1.4 24XLTV Video Driver v.9327)
RasterOps "PaintBoard Turbo XL" (.RasterOps 1.0 PBTurboXL Video Driver v.9327)
“Relax 19" Model 200” (.Color_Video_Display v.9288)
“Spectrum/8•24 PDQ” (.Display_Video_Apple_SpecRice v.3)
“SuperMac ColorCard” v1.97S (.Display_SuperMac_ColorCard v.1)
“Truevision NuVista™ Card” (.Display_Video_NuVista v.3.0)
“Truevision NuVista+™ Card” (.Display_Video_NuVista v.??)

CONTRIBUTORS TO THIS DOCUMENT
Ken Alexander, [e-mail], E-Machines "ColorLink_ SX-T", PowerMac 8500
Mike Alexander, [e-mail], RasterOps ColorBoard 264, why you can't replace boot monitor’s driver.
Michael Bach, [e-mail], more on interrupts.
David Brainard, [e-mail], Quadra 900, 8•24GC, RasterOps 24XLTV, RasterOps PaintBoard Turbo XL, PowerBook 520/540, synching cards.
Tom Busey, [e-mail], RasterOps 8XL, Power Mac 8100/80, 7200/90, SuperMac ColorCard, Apple 2-page monochrome monitor, effect of 8•24GC "accel".
Kyle Cave, [e-mail], Ehman 15", Quadra 700.
Raynald Comtois, [e-mail], multiple interrupts per frame.
Michael Eckert, [e-mail], PowerMac 7100 timing & NuBus bug.
Kaan Erdener, [e-mail], Quadra 660AV.
Rhea Eskew, [e-mail], Psychophysics Display Interface.
Bart Farell, [e-mail], Quadra 840av, color cycling.
Patrick Flanagan, [e-mail], DOME Md Imaging Card, Radius GS/C
Mike Garver, Lapis Dual Page Video, Spectrum/8•24 PDQ.
Tony Hayes, PowerBook 180.
Gregory Jackson, [e-mail], DOME Md Max video card.
Richard Kunert, [e-mail], PowerMac 7500,8500,9500.
Sergei Kurkin, [e-mail], GDSetPageDrawn and GDSetPageShown
Steve Lemke, [e-mail], ShieldCursor.
Jan Linder, [e-mail], Quadra 630.
Jan-Eric Litton, [e-mail], PowerMac 8100/80
Brian McElree, [e-mail], PowerMac 9500
David Rose, [e-mail], TrueVision NuVista+, Mac LC II.
Ariel Salomon, [e-mail], Centris 610
Dan Sears, [e-mail], System 7.5.1, Apple Power Macintosh 6100/60av.
Steve Shevell, [e-mail]: RasterOps “Paintboard Turbo XL”.
Paul Sowden, [e-mail], video bandwidth.
Scott Stevenson, [e-mail], Power Macintosh 8100/80.
Fernando Urbina, [e-mail], PowerMac 7500, 8500.
Marty Wachter, [e-mail], Quadra 840AV.
Beau Watson, [e-mail], 9500 w Radius Thunder 30/1600 PCI video card.
Karsten Weber, [e-mail], synching two cards
Wei Xie, [e-mail], E-Machines "ColorLink_ SX-T", bug in SetEntriesQuickly for Apple 8•24 in Quadra 840AV.

Please send any corrections or additions to [e-mail]